Do we really need the lock in this method? As in: Is it really possible that two threads try to call this method simultaneously? Or is the problem just that there are two threads calling this method quickly after each other, and one of them does not (always) see the result of the previous call by another thread? And would in the latter case just making stream volatile be enough?

The reason for asking is mainly because:

1. If it is so that multiple threads can call this method simultaneously, from where does that happen? (If it is guaranteed that it does not happen in parallel, then the rest of this can be ignored)
2. If that happens from both computeNext() and initiateStreaming(), then a potential follow-on problem could be that the call from computeNext() is executed first, and that will then not set a value for streamMessageListener.
3. And otherwise; If both parallel calls come through initiateStreaming(); Could we instead synchronize those calls? Or somehow prevent that from happening in parallel?

volatile didn't actually fix the issue. Let me try to figure out the issue at the root.

Issue:

1. We are trying to request for initial chunks in startStream which returns the stream.
2. We are trying to request chunks before stream object returned to startGrpcStreaming in ResumableStreamIterator
3. Because of this, chunk is received first and it created ProduceRowsRunnable thread and internally it called GrpcResultSet#next() and that internally ResumableStreamIterator#computeNext() which creates the stream if it's null
4. Due to this reason, 2 begin transaction were started which is causing the the test failure.

@olavloite I have shared the events with you in chat which confirms this behaviour.